Skip to content

Conversation

@amsanghi
Copy link
Contributor

@amsanghi amsanghi commented Nov 6, 2025

Pulled in OffchainLabs/nitro#3965
Related to NIT-4070

fjl and others added 30 commits September 26, 2025 11:41
Bail out of decodeHash when the raw hex string is longer than 32 byte before actually decoding.
---------

Co-authored-by: lightclient <[email protected]>
Decode the modified transaction and verify the value differs from original.

---------

Co-authored-by: lightclient <[email protected]>
Fix incorrect error messages in TestVerkleTreeReadWrite and TestVerkleRollBack functions.
Introduces a new tracer which returns the preimages
of evm KECCAK256 hashes.

See #32570.

---------

Co-authored-by: Sina M <[email protected]>
Co-authored-by: Sina Mahmoodi <[email protected]>
Adds Amsterdam as fork config option.

Co-authored-by: lightclient <[email protected]>
ref
https://github.com/ethereum/execution-apis/blob/main/src/engine/osaka.md#cancun-api

> Client software MUST return -38005: Unsupported fork error if the
Osaka fork has been activated.

---------

Signed-off-by: Delweng <[email protected]>
Co-authored-by: rjl493456442 <[email protected]>
Fixes an error message in TestReplication
Removes a redundant check in TestCreateAccessListWithStateOverrides
These functions were previously ignoring the error returned by both
`statedb.Commit()` and the subsequent `state.New()`,
which could silently fail and cause panics later when the `statedb` is
used.
This change adds proper error checking and panics with a descriptive
error
message if state creation fails.

While unlikely in normal operation, this can occur if there are database
corruption issues or if invalid root hashes are provided, making
debugging
significantly easier when such issues do occur.

This issue was encountered and fixed in
gballet/go-ethereum#552
where the error handling proved essential for debugging

cc: @gballet as this was discussed in a call already.
Looks like we forgot to update names when copying.
- Replace outdated NewFreezer doc that referenced map[string]bool/snappy
toggle with accurate description of -map[string]freezerTableConfig
(noSnappy, prunable).
- Fix misleading field comment on freezerTable.config that spoke as if
it were a boolean (“if true”), clarifying it’s a struct and noting
compression is non-retroactive.
Fixes issue #32762 where ChainConfig logging displays pointer addresses
instead of actual timestamp values for fork activation times.

Before: ShanghaiTime:(*uint64)(0xc000373fb0),
CancunTime:(*uint64)(0xc000373fb8)
After: ShanghaiTime: 1681338455, CancunTime: 1710338135, VerkleTime: nil

The String() method properly dereferences timestamp pointers and handles
nil values for unset fork times, making logs more readable and useful
for debugging chain configuration issues.

---------

Co-authored-by: rjl493456442 <[email protected]>
Extend the chain banner with blob config information.

Co-authored-by: Felix Lange <[email protected]>
The TxPool.signer field was never read and each subpool (legacy/blob)
maintains its own signer instance. This field remained after txpool
refactoring into subpools and is dead code. Removing it reduces
confusion and simplifies the constructor.
… (#32800)

This PR updates the `payloadVersion` function in `simulated_beacon.go`
to handle additional following forks used during development and testing
phases after Osaka.

This change ensures that the simulated beacon correctly resolves the
payload version for these forks, enabling consistent and valid execution
payload handling during local testing or simulation.
Alternative to #30746, potential follow-up to #30743 . This PR makes the
stacktrie always copy incoming value buffers, and reuse them internally.

Improvement in #30743:
```
goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/core/types
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
                          │ derivesha.1 │             derivesha.2              │
                          │   sec/op    │    sec/op     vs base                │
DeriveSha200/stack_trie-8   477.8µ ± 2%   430.0µ ± 12%  -10.00% (p=0.000 n=10)

                          │ derivesha.1  │             derivesha.2              │
                          │     B/op     │     B/op      vs base                │
DeriveSha200/stack_trie-8   45.17Ki ± 0%   25.65Ki ± 0%  -43.21% (p=0.000 n=10)

                          │ derivesha.1 │            derivesha.2             │
                          │  allocs/op  │ allocs/op   vs base                │
DeriveSha200/stack_trie-8   1259.0 ± 0%   232.0 ± 0%  -81.57% (p=0.000 n=10)

```
This PR further enhances that: 

```
goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/core/types
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
                          │ derivesha.2  │          derivesha.3           │
                          │    sec/op    │    sec/op     vs base          │
DeriveSha200/stack_trie-8   430.0µ ± 12%   423.6µ ± 13%  ~ (p=0.739 n=10)

                          │  derivesha.2  │             derivesha.3              │
                          │     B/op      │     B/op      vs base                │
DeriveSha200/stack_trie-8   25.654Ki ± 0%   4.960Ki ± 0%  -80.67% (p=0.000 n=10)

                          │ derivesha.2 │            derivesha.3             │
                          │  allocs/op  │ allocs/op   vs base                │
DeriveSha200/stack_trie-8   232.00 ± 0%   37.00 ± 0%  -84.05% (p=0.000 n=10)
```
So the total derivesha-improvement over *both PRS* is: 
```
goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/core/types
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
                          │ derivesha.1 │             derivesha.3              │
                          │   sec/op    │    sec/op     vs base                │
DeriveSha200/stack_trie-8   477.8µ ± 2%   423.6µ ± 13%  -11.33% (p=0.015 n=10)

                          │  derivesha.1  │             derivesha.3              │
                          │     B/op      │     B/op      vs base                │
DeriveSha200/stack_trie-8   45.171Ki ± 0%   4.960Ki ± 0%  -89.02% (p=0.000 n=10)

                          │ derivesha.1  │            derivesha.3             │
                          │  allocs/op   │ allocs/op   vs base                │
DeriveSha200/stack_trie-8   1259.00 ± 0%   37.00 ± 0%  -97.06% (p=0.000 n=10)
```

Since this PR always copies the incoming value, it adds a little bit of
a penalty on the previous insert-benchmark, which copied nothing (always
passed the same empty slice as input) :

```
goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/trie
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
             │ stacktrie.7  │          stacktrie.10          │
             │    sec/op    │    sec/op     vs base          │
Insert100K-8   88.21m ± 34%   92.37m ± 31%  ~ (p=0.280 n=10)

             │ stacktrie.7  │             stacktrie.10             │
             │     B/op     │     B/op      vs base                │
Insert100K-8   3.424Ki ± 3%   4.581Ki ± 3%  +33.80% (p=0.000 n=10)

             │ stacktrie.7 │            stacktrie.10            │
             │  allocs/op  │ allocs/op   vs base                │
Insert100K-8    22.00 ± 5%   26.00 ± 4%  +18.18% (p=0.000 n=10)
```

---------

Co-authored-by: Gary Rong <[email protected]>
Co-authored-by: Felix Lange <[email protected]>
Description:
We found a occasionally node hang issue on BSC, I think Geth may
also have the issue, so pick the fix patch here.
The fix on BSC repo: bnb-chain/bsc#3347

When the hang occurs, there are two routines stuck.
- routine 1: AsyncFilter(...)
On node start, it will run part of the DiscoveryV4 protocol, which could
take considerable time, here is its hang callstack:
```
goroutine 9711 [chan receive]:  // this routine was stuck on read channel: `<-f.slots`
github.com/ethereum/go-ethereum/p2p/enode.AsyncFilter.func1()
	github.com/ethereum/go-ethereum/p2p/enode/iter.go:206 +0x125
created by github.com/ethereum/go-ethereum/p2p/enode.AsyncFilter in goroutine 1
	github.com/ethereum/go-ethereum/p2p/enode/iter.go:192 +0x205

```

- Routine 2: Node Stop
It is the main routine to shutdown the process, but it got stuck when it
tries to shutdown the discovery components, as it tries to drain the
channel of `<-f.slots`, but the extra 1 slot will never have chance to
be resumed.
```
goroutine 11796 [chan receive]: 
github.com/ethereum/go-ethereum/p2p/enode.(*asyncFilterIter).Close.func1()
	github.com/ethereum/go-ethereum/p2p/enode/iter.go:248 +0x5c
sync.(*Once).doSlow(0xc032a97cb8?, 0xc032a97d18?)
	sync/once.go:78 +0xab
sync.(*Once).Do(...)
	sync/once.go:69
github.com/ethereum/go-ethereum/p2p/enode.(*asyncFilterIter).Close(0xc092ff8d00?)
	github.com/ethereum/go-ethereum/p2p/enode/iter.go:244 +0x36
github.com/ethereum/go-ethereum/p2p/enode.(*bufferIter).Close.func1()
	github.com/ethereum/go-ethereum/p2p/enode/iter.go:299 +0x24
sync.(*Once).doSlow(0x11a175f?, 0x2bfe63e?)
	sync/once.go:78 +0xab
sync.(*Once).Do(...)
	sync/once.go:69
github.com/ethereum/go-ethereum/p2p/enode.(*bufferIter).Close(0x30?)
	github.com/ethereum/go-ethereum/p2p/enode/iter.go:298 +0x36
github.com/ethereum/go-ethereum/p2p/enode.(*FairMix).Close(0xc0004bfea0)
	github.com/ethereum/go-ethereum/p2p/enode/iter.go:379 +0xb7
github.com/ethereum/go-ethereum/eth.(*Ethereum).Stop(0xc000997b00)
	github.com/ethereum/go-ethereum/eth/backend.go:960 +0x4a
github.com/ethereum/go-ethereum/node.(*Node).stopServices(0xc0001362a0, {0xc012e16330, 0x1, 0xc000111410?})
	github.com/ethereum/go-ethereum/node/node.go:333 +0xb3
github.com/ethereum/go-ethereum/node.(*Node).Close(0xc0001362a0)
	github.com/ethereum/go-ethereum/node/node.go:263 +0x167
created by github.com/ethereum/go-ethereum/cmd/utils.StartNode.func1.1 in goroutine 9729
	github.com/ethereum/go-ethereum/cmd/utils/cmd.go:101 +0x78
```

The rootcause of the hang is caused by the extra 1 slot, which was
designed to make sure the routines in `AsyncFilter(...)` can be
finished. This PR fixes it by making sure the extra 1 shot can always be
resumed when node shutdown.
This pr implements ethereum/go-ethereum#32733
to make StateProcessor more customisable.

## Compatibility notes

This introduces a breaking change to users using geth EVM as a library.
The `NewStateProcessor` function now takes one parameter which has the
chainConfig embedded instead of 2 parameters.
just finisher the sentence

Signed-off-by: Csaba Kiraly <[email protected]>
It uses the slices.Concat and slices.Clone methods available now in Go.
Adds blockTimestamp to the logs in response of eth_simulateV1.

---------

Co-authored-by: Sina Mahmoodi <[email protected]>
This PR does a few things:

- Sets the gh actions runner sizes for lint (s) and test (l) workflows
- Runs the tests on gh actions in parallel
- Skips fetching the spec tests when unnecessary (on windows in
appveyor)
- Removes ubuntu appveyor runner since it's essentially duplicate of the
gh action workflow now

The gh test seems to go down from ~35min to ~13min.
@cla-bot
Copy link

cla-bot bot commented Nov 6, 2025

We require contributors to sign our Contributor License Agreement. In order for us to review and merge your code, please sign the linked documents below to get yourself added. https://na3.docusign.net/Member/PowerFormSigning.aspx?PowerFormId=b15c81cc-b5ea-42a6-9107-3992526f2898&env=na3&acct=6e152afc-6284-44af-a4c1-d8ef291db402&v=2

@amsanghi amsanghi changed the title Merge v1.16.7 geth: Merge v1.16.7 Nov 6, 2025
@cla-bot
Copy link

cla-bot bot commented Nov 11, 2025

We require contributors to sign our Contributor License Agreement. In order for us to review and merge your code, please sign the linked documents below to get yourself added. https://na3.docusign.net/Member/PowerFormSigning.aspx?PowerFormId=b15c81cc-b5ea-42a6-9107-3992526f2898&env=na3&acct=6e152afc-6284-44af-a4c1-d8ef291db402&v=2

@cla-bot
Copy link

cla-bot bot commented Nov 11, 2025

We require contributors to sign our Contributor License Agreement. In order for us to review and merge your code, please sign the linked documents below to get yourself added. https://na3.docusign.net/Member/PowerFormSigning.aspx?PowerFormId=b15c81cc-b5ea-42a6-9107-3992526f2898&env=na3&acct=6e152afc-6284-44af-a4c1-d8ef291db402&v=2

@amsanghi amsanghi marked this pull request as ready for review November 11, 2025 12:36
@amsanghi amsanghi requested a review from eljobe November 11, 2025 12:37
@eljobe eljobe merged commit 494cf84 into master Nov 11, 2025
17 of 18 checks passed
@eljobe eljobe deleted the merge_v1.16.7 branch November 11, 2025 13:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.